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ABSTRACT 

This paper describes a National Science 
Foundation-sponsored project at Louisiana Technological University to 
develop computer-based I'^borator ies for "hands-on" introductions to 
major topics of computer science. The underlying strategy is to 
develop structured laboratory environments that present abstract 
concepts through the use of computer simulations. These simulations 
allow students to explore meaningful, but domain limited, problems 
that are representative of real problems solved by computer 
scientists and computer engineers. The laboratories focus on: 
spreadsheets; relational databases; data structures; graphics; the 
imperative, functional, and logical programming paradigms; and 
digital logic. Types of laboratories that are candidates for future 
development include finite state automata; automatic theorem proving; 
and machine organization and assembly language. In order to insure 
that the laboratory experiences are useful from a pedagogical 
standpoint, a rigorous evaluation program will be conducted. Pre- and 
posttests will be used to measure the changes in, and generalization 
of, problem solving abilities. Standardized instruments for measuring 
student attitudes will also be used. (Contains 11 references.) 
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Abstract ~ 

This paper describes an NSF sponsored project to develop computer-based laboratory experiences for ‘'hands-on" 
introductions to many of the major topics appropriate for an overview of computer sdence. Our underlying strategy is to 
develop structured laboratory environments that are designed to present abstract concepts through the use of computer- 
based simulau'ons. These simulations will allowjstudents to explore meaningful, but domain limited, problems that are 
representative of real problems solved by computer scientists and computer engineers. 



Introduction 

The current student proCle In our "computer literacy" course (CSlOO) is quite heterogeneous. About ‘iO-50% of the 
students are computer science majors, while the remainder are drawn from programs throughout the University. Typically, 
-f 30-40% of the students in CSlOO are women, while approximately 25% of the class is composed of etlmic minorities 

■"* (predominately African American). These students represent a wide range of interesLs and abiliues. Most have little or no 

I background in college-level mathematics. 
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In the vSpring of 1992 we began an effort to adapt this introductory computer science course to a breadth-Orst approach. 
The goal of this approach is to gi\e students an o\erv1ew of the entire computing milieu. The challenge is to dc\*eIop a course 
that is rigorous enough to prepare the computer science majors for the follow-on courses, yet, at the same tinw, be both 
meaningful and accessible to the large number of non-computer science majors who take the course. 

There are several good te.xtbooks av-ailable that present the major aspects of computing such as computer architecture, 
operating s>stems, algorithm development, programming language paradigms, databa^, and networks. Howe\*er, most le.xts 
lack an Integrated laboratory component. To overcome this deQciency we have embarked on a National Science Foundation 
funded project (DUE 9254317) to develop a laboratory environment for a breadth-flrsl computer science overview course. 
This environment is composed of a collection of software modules, collectively know.i as “Watson." We chose the name 
Watson to emphasize that tl^e environment is to act as an assistant that helps the student explore various aspects of 
computing. 

In the past, we attempted to have students complete small assignments using off-the-shelf software in an open lab 
environment. We found that our open laboratories, which are successful for more advanced computer science courses, did 
not work well for CSIOO. The students were overwtelmed by the syntactic details of the various software tools they* were 
expected to use and many students ended up very frustrated. It does not have to be this way. With the proper hardw*are and 
software, students can be presented with a positive learning experience that increases their understanding of, and 
appredation for, compuu'ng. 



Background 

Watson is designed to support a breadth first approach to computer science. Serious discussion of this approach started 
with the Denning committee report [Denning, el al., 19891 that describes a three course sequence for a breadth-first 
Introduction to computer science. This report was the starting point for the development of Curricula 9 1 [Tucker, et. al., 

1991 ] that described the core areas of an undergraduate computer science curriculum as a set of knowledge units within ten 
major topic areas. Fjcposure of students to the breadth of computing a pliilosophy pervasive in these efforts and in our 
laboratories. We have also adopted a philosophy of closed lab sessions and provisions for group work, as recommended by 
the Curricula 91 report. 

The breadth-first approach has inQucnced courses and textbooks for computer literacy. Computer Science: An 
Oi'enietv, by Glenn Brookshear [4th. Fxl., 1994] , is an e.xcellent text aimed at the same student audience as our laboratories. 
We are currently asing this te.xt in our CSIOO course. It avoids the syntactic complexliies of any particular programming 
language or software package and, instead, focuses on the "bigger issues." However, Brooks hears text lacks an integrated 
laboratory component. Another te.xt. The Analytic Engine, by Rick Decker and Stuart Hirshfield, comes the closest to our 
project since it contains an integrated laboratory' environmcnl They state that "students are both relieved titat the course de- 
emphasizes programming and arc interested to find out that there is more to computer science/’ [Decker, 1990. p. 235] . 
Another Interesting approach i** provided by Alan Biermann in his text Great Ideas in Computer Science: A Gentle 
Introduction [ 1990]. These types of changes to computer liicracy instruction are discussed in an e.xcellent paper, “The New 
Oencration of Computer Literacy," by' Paul Myers [ 19891 . 

A recent region, America's Academic Future, issued by the National Science Foundation [NSF, 1992), idemifies many of 
tile larger issues fa*, ing /\mericar education. One of the primary recommendations is to "Encourage the development of 
discovery- oriented .earning enrironments and technology-based instruction at all educational levels." [p. 4) There is a 
particular emphasis on the use of "new communication, information, and visualization technologies." We strongly believe the 
goals and objetaivco of our project are in concert with these recommendations. 



The Laboratory Enviromnent 

while it would be tempting to simply search the Internet for public domain packages that cover the ‘opics of in>erest, we 
believe that such an approach would be coo: ' :d to failure with freshman-level students. At this level, sym x and “look and 
feel" issues are major hurdles. A freshma? student presented with many unrelated environments would spend the majority' of 
the semester jast learning how to use the software environments, rather than actually solving problems with them. It is clear 
that a single, consistent, flexible sofiw'aro environment, specifically designed to support computer-based problem solving, is 
needed. 

Our laboratory modules incorporate a number of guidelines we have developed based on our experiences introducing 
freshmen to computer science. These guidelines include: 

• Present a uniform environment that mininuzes the need for keyboard input and prevents tiic introduction 
of syntax errors. 
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• Provide a consistent help system that includes information on how to use the environment, as well as 
high-level problem solving assistance. 

• Allow for both “tutorial" and “guided discovery” laboratory experiences. 

• Allow for flexibility and ease of modification. 

In addition, as a practical matter, the software must be able to run on a variety of computer platforms such as PCs and 
LINK workstations. 

We have observed that many CSlOO students feel uncomfortable in front of a keyboard. The mechanics of typing and 
entering commands and correcting mistakes are difficult for some. A more widely recognized problem is the difficulty 
students have with programming language syntax. Our approach to these problems Is to use syntax directed editors so that 
only syntj ctically correct “programs” can be entered, and to limit keyboard input wherever practical. 

The help system In each of the laboratory modules has been designed to provide two types of assistance: information 
about the software laboratory environment, and problem solving assistance. To Invoke the first typ'i of help the student 
presses a button marked “What is?” and then clicks on the item for which help is to be provided. A popup window appears 
with a deicription of that item. The second type of help Involves problem solving advice. Initially, when laboratory exercises 
are written, the faculty members authoring thoseixercises provide a collection of helpful hir ts to avoid common pitfalls. Tliis 
advice Is incorporated into the software and displayed whenever the student indicates their need for assistance. 

In order for Watson to gain the widest possible acceptance, we do not want to limit it to any one pedagogical style. 

Instead, our goal is to build enough flexibility into the software so that it can be used with a range of pedagogical techniques 
from fully scripted mtorials to directed discovery. Flexibility is also Important in another sense. It should be possible for 
instructors who use this software to adapt It to their own style with as Uttle pain as possible. For these reasons, our sofovare is 
organized into three distinct “levels”. The first'level, the “message level,” is a keyed text file. The existence of this level allows 
instructors with limited programming ability to quickly change certain aspects of a laboratory exercise^ such as the dcnniiion 
of terms, or explanation of a problem. The second level, the “activity level , Is a C source program that incorporates a 
number of speo'alized functions that allow this level to sense and control activities at the underlying level. Instructors with a 
working knowledge of C programming should be able to change most aspects of a laboratory exercise without needing to 
learn the details of the underlying software environment. The final level is the “laboratory environment level which actually 
defines all of the software objects that make up a laboratory environment. 

A final requirement, that we established early on, was that all software developed under this project must rtin on a 
variety of hardware platforms, especially LNK workstations and Windows-based PCs. The ability to run on Macintosh 
computers was also considered important. To meet these requirements, we selected SUIT, the Simple User Interface Toolkit 
[Conway, 1992] . This product, developed at the University of Virginia, provides a flexible, easy to use, extensible environment 
that allowed for rapid prototyping of the user interface and provided for cross platform compatibility. SI IT is currently 
available under X-windows, Microsoft Windows, DOS, and Mac OS, and is free of charge for academic projects. 

Description of the Laboratory Activities 

We a'"' using our first year funding to develop eight laboratories. We describe two laboratories in detail below and 
provide a brief description of the others. F.ach lab has ttvo levels of presentation: a concrete, hands-on component where 
students manipulate objects and observe results and an abstract level where the underlying theory can be used to produce the 
same results. 

Spreadsheet Laboratory 

Tliis simplified spreadsheet program allows students to enter arrays of data and to calculate additional data based on 
existing data. Sample calculations arc summation, average, and projection of values based on specified growih rates. I nlike a 
real spreadsheet package, this environment Is tightly consuained and monitored. If the student starts going far astray in 
complcUng an activity, the system provides Interactive help to get him or her back on track. The concrete level is the data a.s it 
appears in the table and that can be manipulated through mouse input. The abstract level includes the malliemaUcal 
equations that define the relationships between data values. 

Relational Database Laboratory 

The main activities In this lab Involve composing queries to answer specific questions concerning one or more tables of 
data. An initial academic database is provided with three tables: a student infonnation table, a uiblc of classes attended, and a 
facility table that includes classes taught. The dau has been simplified so that the student can focus on the pnmaiy acuvity: 
database queries. Queries involve one or more tables and ase of llie operafions project, select and join, lliere am ttvo modes 
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of operation: quei)' by example (the concrete level) and query by relational equation (the abstract level). With query by 
example selecting a column heaings is equivalent to a project operation, matching two column headings from two tables Is a 
join, and applying restrictions to values Is a selection. As th^ concrete actions take place, the corresponding relational 
equations appear on the screen. During the second part of the assignment the student has to enter relational equations 
directly to obtain the desired results. 

Data Structures Laboratory 

The data structures lab is Intended to familiarize students with the behavior of common data structures, such as stacks, 
queues, and trees. For example, a stack data structure Is presented on the screen as a graphical object that may be activated 
by clicking on buttons such as “push" or “pop," the concrete level of operation. At the same time, a sequence of instructions 
is displayed. At the abstract level the student must solve a problem by entering a correct list of instructions and executing 
them. A sample task might be creating the reverse of a given stack. 

Graphics Laboratory 

The graphics laboratory introduces students to several fundamental concepts in computer science: declaration of object 
types, assignment of values to objects, and interactive manipulation of objects. A complete screen layout appears in Figure 1. 
The upper left window contains variable declarations, where choices such as point, line, circle or polygon are selected irom a 
menu of push buttons. Objects must be declared before they are assigned values In the program code window. Commands 
such as draw and color produce changes in the drawing window. The bottom tutor window can display a description of the 
problem to be solved or provide assistance wten errors In the student’s code are detected. 




Figure 1. Screen Layout for the Graphics Activity 

There is a duality between the program declarations and code (the abstract level), shown in the left windows, and the 
picture constructed in the drawing window (the concrete level). The student can “paint" a picture in tlie drawing window and 
watch the corresponding declarations and commands appear in the left windows, or the student can enter declarations and 
commands to cause a picture to be drawn In the ri^t window. Students should be able to draw simple pictures using either 
approach. 

The Imperative, Functional, and Logical Programming Paradigms 

All three programming paradigms use syntax directed editors designed to allow students to enter syntactically correct 
programs and to minimize the use of keyboard inpuL Programming assignments are very short since the goal is not to teach 
the student to program well in any one language, rather It Is to expose students to a variety of programming paradigms. Tlie 
semantics of a program can be defined by Its input/output behavior; wo consider this the abstraction of the program. The 
actual Implementation In a particular paradigm or using a particular technique (e.g., Iteration versus recursion) represents 
the concrete level of understanding. 
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The Imperative programming language Is subset of a Pascal-like language vsith type declarations and commands for 
selection^ Iteration, and procedure Invocation, Procedures wth or without parameters can be declared, All entry Is via an 
editor that Insures the svmtix and static semantics of the program are correa Laboratory assignments do not Involve lengthy 
programs, rather most focus on a few very small procedures designed to work together to accomplish a particular task. 




Figure 2. The Syntax Directed Editor for Lisp 

We use the Lisp editor, as pictured in Figure 2, to illustrate a syntax directed editor; the other editors are of similar 
design. The following pull down menus are available: Control (defun, cond), Lists (car, edr, cons, list, append). Tests (eq, 
null, atom, lisip, zerop), Math (+, -, *,/)» and Constants (t, nil, quote, (<list>) ). A function that is deOned for the first umc 
Is normally entered in a top down manner by selecting a defun option, naming the function, spedf^ing the parameter list and 
spedlying the function body. Once the function name and parameters are spedfied, these names appear in the windows 
called' “Function List” and “Parameter List”. From this point on, references to function names and parameters are tlirough 
selection, not keyboard entry. 

Lab activities involve writing simple functions that may manipulate lists, such as the “last" function shown, or perform 
simple arithmetic operations, such as a factorial function. . We do not allow any selq operations and wc depend on recursion 
to perform repetition. The intent of this lab is to expose students to the “look and feel" of a functional programming 
language. 

The logic programming laboratory will use a syntax directed editor for a subset of Prolog tliat Is similar to the oi 
described above for Lisp. Logic programming is introduced from a relational peisoective, siinilar to the academic (Luahasc 
used in the Relational Database Laboratory. Next the list manipulation facilities of Prolog are introduced. Some of the simpler 
functional programming activities are replicated for Prolog. 

Digital Logic Laboratory 

This laboratory covers tw'o topics: combinatorial logic and sequenilal logic. The concrete level of operation arc the gates 
and ilip-llops used to build circuits; the abstract level is the Boolean equation that represents the behavior of the circuit (or 
the timing diagram for a sc<iuential circuit). Students first build simple combinatorial dreuits using AND, OR and NOT gates. 
The lab environment allows dreuits to be named and then recalled as “black box" devices. For example, gates are used to 
build a half-adder which is stored in a user defined library. The half-adder is used to build a full- adder, which In turn can be 
used to build a four bit adder. A major goal of tills lab is to be able to write a Boolean equation for any connection In the 
circuit or, given a Boolean equation, build the corresponding dreuit. In the final combinatorial logic activity the student 
builds a latch in the form of a D fiip-fiop and then adds a dock signal to obtain the familiar edge-triggered D (lip-fiop. Sliift 
registers, counters, ring counters, and parallcl-to-serial converters are studied. Students are introduced to the use of timing 
(liaprams to analyv£ sequential circuits. 



•'Reaeating the Rei'olution " 



.W 



O 

ERIC 



6 



BEST COPY AVAIUBLE 



-V 

■A 

a 



JVi;.-tLi*»*\’C%*i.*L'X'j«'i'N'*-‘^--^»~ii^'t^'*-* i*«y*^»A.%'5'«U'^*»efc-/. .. ..-'♦Wi.. n*,.--,-..^ «^, . .. - 



:3 



n 

•*1 

'•« 

-,•3 

;-t' 

: ti 

>1 

'-i 

Vt 

.o 

•i 



Possible Laboratories for Future Development 

We hope to develop addilional laboratories to cover a broader range of topics. This would allow an instructor to pick 
and choose topics to meet the needs of a particular target audience. For example, a computer Dteraq course targeted for 
business or education majors may elect to cover the applications and programming language paradigms, but might not cover 
the hardware and theory oriented components. On the other hand, a computer Uteraq course for engineers may elect to de- 
emphaslze the busines^^ components and include all the hardware-oriented components. Here we only briefly describe three 
of the laboratories that are candidates for future development and list some others. 

Finite State Automata Laboratory 

Students would work in a graphical environment where thq can construct and test simple flnite state automata. An 
example challenge might be: design an FSA to accept a siring of O’s and 1 's if the pattern 100 appears anywhere in the string. 
A sample solution appears below. 




Automatic Theorem Proving Laboratory 

Automatic theorem proving is first introduced with the logic programming laboratory. This lab focuses on two main 
topics: translation from English to first order predicate calculus to clausal form and then mechanically constructing a 
resolution proof. Although this topic may appear to be bqond a typical student in a computer literaq class, we have had 
some success In the past given a well designed lab activity to introduce resolution theorem proving [Gasser, 1992] . 

Machine Organization and Assembly Language 

We will devise a simple assembly language whose execution an be simulated with a “model” computer. This model will 
contain the instruction register, decoding logic, program counter, RAM memoq, arithmetic-logic unit, and register set. 
Students will be able to enter assembly language programs and execute them, step-by-step. In this way students will learn 
about op codes, addressing modes, and data manipulation for a simple computer. 



Other topics we may develop labs for are: 

• Artificial Intelligence Laboratoq 

• Software Engineering laboratoq 

• Programming Language Translation Laboratoq 

• Operating Svstems Laboratoq 

• Distributed and Parallel Processing Laboratoq 

• Ethics and Computing 

In addition to constructing more laboraloq modules, we plan to extend the work described in this paper in a number of 
directions. One direction we wish to explore is thc4iseof multimedia, including digitized voice and video. We are also 
interested in innovative input techniques such as speech recognition and pen-based input 

Assessment, Evaluation and Availability of Materials 

We intend to insure that the laboratoq experiences are useful from a pedagogical standpoint, by following a rigoroiu; 
evaluation program. We are conducting our formative evaluation using the following approaches: 

• the teaching is being monitored by laboratoq developers who have not been assigned as the instructor 

• examination results are scrutinized to indiatc laboratoq strengths and weaknesses 
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• the laboratory sessions are monitored by graduate students who report on general use of the laboratory 
software 

• laboratory sessions are monitored electronically by keeping a history of activities for each student 

• students are asked to evaluate the course content and laboratories using instruments spedGcally designed 
to evaluate these course materials 



students complete the standard evaluation forms 



We plan to use pre and post tests to measure the changes in, and generalization of, problem solving abilities. 
Standardized instruments for measuring student attitudes will also used 

Once the laboratories are fully developed and refined at Louisiana Tech University, we plan to make them available over 
the Internet using ftp. We have initiaily targeted two platforms: Sun Sparcstations and IBM PCs. Almost any Sparcstau'on wth a 
color monitor can be used. The IBM PCs require Windows 3.0 or higher and SVGA graphics support. 
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